In this article I want to explore different aspects of scaling a company that need to be taken into account if you're trying to grow exponentially. Generally when discussing about growth we consider revenue growth to be the metric we're measuring. One thing that is important, and that is considered throughout the article, is to be a profitable company. There's no point in growing exponentially if it is unsustainable or your expenses are always going to be superior to your profits.

In the best scenario, your business grows exponentially without requiring any additional human power. The second best case is that it grows sublinearly, meaning that as demand grows, the amount of people required to support the company grows slower than the demand itself. Past this point, growth either matches with how many people need to be hired, or worse, growth is slower as you hire more people. Here you may have exponential human power growth to get linear (or sublinear) revenue growth.

When hiring people, you need to be able to onboard them while having as little impact as possible on the existing employees. If existing employees need to spend time onboarding new employees, then nobody is working on product development or support during that period. Here again, you want the number of people responsible to onboard and train new employees to be smaller than the number of people being onboarded. In other words, you want the ratio of onboarded to onboarders to be higher than 1 to 1.

When a company grows exponentially, every time the company effectively double due to new hires, the culture is now at risk of instability. If for instance 100% of the existing employees were following the existing culture, and 100% of the new hires have a different culture, then there will be a culture clash with no specific half of the company being in control of culture. Unless culture continues to be managed through the process of onboarding, the initial group of people and their culture will rapidly become diluted.

We're not made to interact with dozen or hundreds of peers. As such, it is close to impossible for an individual to work with more than let say 10 direct peers. This means that teams or groups need to be created. This also means that interaction between teams needs to be managed somehow. Having multiple people from a team interact with another team leads to the implicit creation of a larger 20 people team, which does not work very effectively. On the other hand, having single points of contact between teams is a surefire way to have single points of failure. In this specific instance it is definitely necessary to have at least 1 or 2 redundancies.

It is also important to keep the people that have been at the company the longest. As the doubling period effectively divides by two the average duration an employee was with the company, losing those senior employees will speed up the drop in employee average tenure. This means that a lot of institutional knowledge will be lost along the way. This would also mean that you should possibly prefer to keep a senior employee at the cost of hiring a new employee, unless you believe that the amount of time necessary to onboard and be effective is lower than the average employee tenure.

The process of onboarding should be optimized as much as possible.

Anything that requires human power to scale linearly or superlinearly with itself needs to be optimized so that it grows sublinearly.

The onboarding process described here is specific to a software engineer joining a tech company. While some/most of the items may still apply to any job where you mainly work from a computer, the assumption will be that you develop software as an individual contributor.

Week 1

• Setup laptop
• Access to slack
• Access to zoom
• Setup calendar reminders
• Initial meeting with buddy
• Access to git central repository
• Installation of development tools/languages
• Request software licenses
• Access to CI/CD
• Find where task management is done
• Find the documentation to build projects
• Connect 1 on 1 with each member of the team
• Meet with manager 1 on 1
• Define a 30-60-90 days plan with manager
• Verify access to various systems (SSO, code repository, insurance company, payroll company, etc.)
• End of week meeting with buddy

Week 2

• Setup and run the one step build process
• Determine how are features/tasks prioritized, who prioritizes features/tasks
• Review the team documentation
• Review team practices/processes documentation (code style, code review, standups, planning, retrospective, demos)
• Review common vocabulary, terminology, glossary documents
• First PR + code review
• Review the career ladder of the position

Week 3

• Review user definition, use cases, requirements
• Read prior team meetings notes

Week 4

• Identify how deployments are done
• Review the team roadmap
• Determine where I can have the biggest impact
• Determine a timeline where I'll have reached my 80/20 at the company
• Determine the maturity of existing projects
• Determine how fast can we iterate on certain aspects given the team/company composition
• Identify the core/principal/staff contributors and their contributions
• Review the architecture of the system
• Review the database architecture
• Learn about "how we got to this point"
• Determine whether the product is a monolith or micro-services
• Identify which (3rd party) tools are used by the team/company
• Determine the portfolio of STARS situations of the team/company
• Determine a rough estimate of the number of people in the different organizations
• Connect 1 on 1 with important collaborator in other teams
• End of first month meeting with buddy
• First month performance review with manager
• Informal 360-degree review with manager and peers on adaptation
• Month 1 job satisfaction review

Week 8

• Team interaction diagram
• Month 2 job satisfaction review

Week 12

• Month 3 job satisfaction review